Overview

Neo4j has a large PNPM monorepo with workspaces. The team that owns the browser workspace wants to be able to scan just the browser target. But the pnpm strategy doesn't allow you to target workspaces.

This PR fixes that by allowing you to target individual workspaces as targets, and showing those workspaces when you run fossa list-targets.

One thing this needed beyond the yarn/npm port. Workspace links: pnpm-lock.yaml groups direct dependencies under an importers: key per workspace, one key per workspace path — browser, server, and so on. A dependency on a sibling workspace is the exception: pnpm writes version: link:../shared instead of a real package entry, so what browser gets from shared is recorded only under shared's own key. Merging every importer into one graph hid that, but scoping to browser alone would have dropped it. expandWorkspaceLinks follows each link to the workspace it names, transitively, so a scoped result still covers everything the selected workspace reaches.

Unnamed roots behave as they already do for yarn and npm: a root package.json with no name gets no targets at all, its members included. A target is selected by package name, so a nameless root can never be named — and offering the members without it would let an unfiltered scan silently drop the root's own dependencies. All or nothing is the safe answer, but from the outside it looks like a bug, so discovery now warns and says to add a name, which is a one-line change.

Two things found along the way are split into their own PRs: the package.json fallback emitting npm+left-pad$catalog: for catalog: specifiers (#1765), and the missing docs for the target: field of .fossa.yml (#1764). Once #1764 lands, its wording should be extended from "yarn or npm" to include pnpm.

Acceptance criteria

fossa list-targets on a pnpm workspace lists each member, and fossa analyze --only-target 'pnpm@./:browser' reports only that member's dependencies instead of the whole workspace's.

Testing plan

Download the repro attached to ANE-3125. This is a pnpm project with a root named repro-root, and workspaces called browser and server.

Browser has one dependency, left-pad. Server has is-odd

make install-dev
cd ~/Downloads/pnpm-repro

Now test that list-targets shows you the per-member build targets when you use fossa-dev:

fossa list-targets
[WARN] fossa list-targets does not apply any filtering, you may see projects which are not present in the final analysis.
Found project: pnpm@./
Found target: pnpm@./

fossa-dev list-targets
[WARN] fossa list-targets does not apply any filtering, you may see projects which are not present in the final analysis.
Found project: pnpm@./
Found target: pnpm@./:browser
Found target: pnpm@./:repro-root
Found target: pnpm@./:server

Analyzing the browser target should report left-pad as its only dependency. Analyzing server should report is-odd as its only direct dependency, with is-number as a transitive. Without a target, or with a target of pnpm@./, you should see all three dependencies.

fossa-dev analyze --output --only-target 'pnpm@./:browser' | jq .sourceUnits

fossa-dev analyze --output --only-target 'pnpm@./:server' | jq .sourceUnits

fossa-dev analyze --output --only-target 'pnpm@./' | jq .sourceUnits

Put this in .fossa.yml and run fossa-dev analyze --output with no flags. The result should match fossa-dev analyze --output --only-target 'pnpm@./:server' | jq .sourceUnits

version: 3
targets:
  only:
    - type: pnpm
      path: ./
      target: server

Finally, remove the name line from the root package.json.

• fossa-dev list-targets should result in a bare pnpm@./ and the warning below.
• fossa-dev analyze --output with no filter reports the whole workspace exactly as master does
• fossa-dev analyze --output --only-target 'pnpm@./:browser' also reports the whole workspace, which is the pre-existing rule for a project without targets and the reason the warning has to be here.

[WARN] Workspace root /Users/you/Downloads/pnpm-repro/package.json has no `name`, so its members are not offered as build targets and the whole workspace is analyzed as one unit. Add a `name` to select members individually with --only-target or targets.only in .fossa.yml.

Risks

Metrics

None added.

References

• ANE-3125: pnpm — cannot scan an individual workspace member. Customer tickets TKT-15849 and TKT-14547.
• #1764 and #1765: split out of this PR.

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_015zRtempnk5Led4xWQTqVfb